Day 23 不小心錯過,斷賽了。
因為一來寫文章也花很多時間,二來後面也沒什麼跟 Hydra 直接相關的主題,就決定先退場了。
今天最後一篇,來講講 OP 與 RP 相關的 Metadata,但跟 Hydra 沒有直接相關。
回顧一下第一天有提到的:
職責單一的微服務
Hydra 所有東西幾乎都是透過 API 提供,官方有提供文件參考。而 OpenID Connect 則有一份協定 OpenID Connect Discovery 說明 OP 可以如何提供相關資訊讓應用程式知道該如何串接。這份資訊稱之為 OpenID Provider Metadata,可以透過 GET http://127.0.0.1:4444/.well-known/openid-configuration
取得資訊,它是一個 Key-Value 的 JSON 物件,以下說明目前有接觸到的資訊與其對應的欄位:
欄位 | 必要 | 說明 |
---|---|---|
issuer |
REQUIRED | 發行者的 URL,它的內容會與 ID token 的 iss 欄位的值完全一致。驗證 ID Token 的時候會需要它。 |
authorization_endpoint |
REQUIRED | OP 啟動身分驗證的入口,也就是應用程式轉導到 OP 的第一個入口。 |
token_endpoint |
REQUIRED / OPTIONAL | 應用程式向 OP 取得 Token 用的端口。 |
userinfo_endpoint |
RECOMMENDED | 取得 Access Token 的資訊所呼叫的端口。 |
jwks_uri |
REQUIRED | 這裡是要驗證 ID Token 用的公鑰。 |
scopes_supported |
RECOMMENDED | OP 支援授權哪些 scope。 |
response_types_supported |
REQUIRED | 指 response_type 有哪些可以用。 |
response_modes_supported |
OPTIONAL | 指身分驗證請求的 response_mode 有哪些可以用。 |
grant_types_supported |
OPTIONAL | 指 token_endpoint 可以請求的驗證類型(grant_type )有哪些,如 authorization_code 、implicit 等 |
服務發現非常好用,主要是因為 OpenID Connect 協定上都有描述流程為何,因此今天如果要串接某個 OP 時,只要打開這個訊息就知道怎麼串接了。這個功能也可以應用在寫 RP 程式上,比方說:
$providerMetadata = $op->discover();
// ...
return Redirect::away($providerMetadata->authorizationEndpoint() . '?' . $query);
與 OP 相對的 RP,也有定義 Metadata,不過是定義在動態註冊上,相關文件為 OpenID Connect Dynamic Client Registration 1.0。
這裡不特別說明動態註冊的應用場景,主要是要講 Client Metadata,也就是 RP 相關的 Metadata。下面舉幾個相關的欄位:
欄位 | 必要 | 說明 |
---|---|---|
redirect_uris |
REQUIRED | RP 註冊的轉導向 URI。 |
response_types |
OPTIONAL | RP 可使用的回應類型。 |
grant_types |
OPTIONAL | RP 可使用的授權模式。 |
contacts |
OPTIONAL | RP 維護者的聯絡方法。 |
client_name |
OPTIONAL | RP 名稱。 |
logo_uri |
OPTIONAL | RP 的 logo。 |
client_uri |
OPTIONAL | RP 的首頁。 |
這份資訊有兩種類型,一種是 RP 的 Metadata,像是 RP 名稱或 Logo 等。這能讓 OP 在身分驗證與授權流程中使用,像在授權的時候就能夠提示使用者「您願意授權 XXX 應用程式讀取您的 Email 資訊嗎」之類的。
另一種類型則是 RP 向 OP 註冊的串接方法,如 redirect_uris
或是 grant_types
等。OP 可以透過審核流程,來讓指定的 RP 使用指定的授權方法。
而立場對調,RP 在向 OP 註冊前,也能先從這份文件了解應該準備的資訊有哪些。
失敗了,只好明年再重來。剛好 Hydra 目前也在 V2 Alpha 版,剛好明年可以寫 2.0,敬請期待。